SUPPORT SYSTEM FOR SETTING PRICE OF TRANSACTION TARGET ARTICLE 



BACKGROUND OF THE INVENTION 

1. Field of the Invention 

[0001] The present invention relates generally to a support system 
for setting a price of a transaction target article, and more 
particularly to a transaction target article price setting 
support systemapplicable to a computer network based transaction 
system. 

2. Description of the Prior Art 

[0002] With a spread of the Internet over the recent years, the 
commercial transactions are daily conducted via the Internet. 
[0003] A conventional transaction information system for 
providing services for commercial transactions via the Internet , 
especially a used article transaction information system, 
includes a sales bulletin board (electronic bulletin board 
system) on which a sales price of a transaction target article 
is put up, an auction system in which a participant who sets 
the highest price for the auction article makes a successful 
bid of this article, and so on. 

[0004] In the Internet-based commercial transactions described 
above, the users of the Internet are allowed to put up sales 
target articles on the sales bulletin board and participate in 
the commercial transactions as sales applicants such as entering 
the articles in the auction. 

[0005] According to the used article transaction information 
system, the sales applicant puts up his or her own transaction 
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target article on the sales bulletin board or enters it in the 
auction. In this case, the sales applicant is able to set a 
price for the transaction target article (a minimum price in 
the auction) as the applicant desires . On the occasionof setting 
the price by the sales applicant, however, the conventional 
transaction information system provides no information for 
setting the price. 

[0006] A great majority of the sales applicants are, however, 
amateurs with respect to how to sell the articles offered, and 
know nothing about the current market prices for sale of the 
transaction target article. The sales applicant therefore 
tends to set the price higher than the market price, with the 
result that a purchaser can not be found, or conversely, sets 
the price lower than the market price, with the result that the 
sales applicant becomes aware of having made an unprofitable 
transaction after the sale. 

SUMAMRY OF THE INVENTION 

[0007] It is a primary object of the present invention to provide 
a support system for setting a price of a transaction target 
article, by which a sales applicant is able to set a proper price 
of the transaction target article. 

[0008] To accomplish the above object, according to one aspect 
of the present invention, a support system for setting a price 
for a transaction target article in response to a request, 
comprises a storage unit storing identifying information for 
the transaction target article and quality information for 
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indicating the quality of the transaction target article, a 
receiving unit receiving the identifying information and the 
quality evaluating information for evaluating a quality of the 
transaction target article for which a price should be set by 
the requester, a reading unit reading the quality information 
coincident with the received identifying information and quality 
evaluating information, and a transmitting unit for transmitting 
the assessed quality information to the requester. 
[0009] According to the present invention, the quality information 
is transmitted to the requester as support information for 
setting the price, and hence the price can be set with the quality 
information being used as a key factor. 

[0010] The above support system according to the present invention 
may further comprise a transaction achievement information 
storage module for storing completed transaction (achievement) 
information containing transaction price information for 
transactions actually completed with respect to the transaction 
article, and a statistic value calculating unit for calculating 
a statistic value for the transaction price when at least one 
transaction achievement information coincident with the input 
identifying information and quality information is read-out from 
the transaction achievement information storage module, and the 
transmitting unit may transmit the calculated statistic value 
of the transaction price . The statistic value is, for example, 
an average value of the transaction price. Thus, the statistic 
value of the transaction price based on transaction achievements 
is transmitted as support information to the requester, and 
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therefore the requester is able to set the price more properly. 
[0011] The support system according to the present invention may 
further comprise a necessary time related information storage 
module storing information on the necessary time for a 
transaction to actually be completed with respect to the 
transaction target article. The statistic value calculating 
unit may calculate a statistic value of the necessary time on 
the basis of a single item or plural items of transaction 
achievement information, and the transmitting unit may transmit , 
to the requester, the statistic value of the necessary time 
together with the statistic value of the transaction price . The 
statistic value is, for instance, an average value of the 
necessary time. 

[0012] The support system for setting the price of the transaction 
target article according to the present invention is capable 
of supplying the requester with the quality information and the 
statistic value serving as key factors in setting the price, 
whereby the sales applicant is able to set the proper price of 
the transaction target article. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0013] FIG. lA and IB are high-level diagrams of a network 
architecture of a transaction system in one embodiment of the 
present invention; 

FIG. 2 is an example of a hardware architecture for the 
server and client in one embodiment of the present invention; 

FIG. 3 is a server process flowchart of the first embodiment 
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of the present invention (sheet 1) ; 

FIG. 4 is a server process flowchart (sheet 2) ; 

FIG. 5 is an example of an input display screen; 

FIG. 6 is an example of a vehicle component database; 

FIG, 7 is an example of a transaction history database; 

FIG- 8 is an example of a price range table; 

FIG. 9 is an example of a message displayed to a sales 
applicant corresponding to process step S13; 

FIG. 10 is an example of a first collection table; 

FIG. 11 is an example of a message displayed to a sales 
applicant corresponding to process steps S15 and 316 j 

FIG. 12 is an example of a second collection table; 

FIG. 13 is an example of a message displayed to a sales 
applicant corresponding to process steps S18 and S19; 

FIG. 14 is an example of an input screen in a second 
embodiment ; 

FIG. 15 is an example of an assessment item database; 
FIG. 16 is an example of a second input screen; 
FIG. 17 is an example of an assessment rank table; 
FIG. 18 is an example of a message displayed to a sales 
applicant ; 

FIG. 19 is a server process flowchart showing an operation 
of the server in the second embodiment (sheet 1) ; 

FIG. 2 0 is a server process flowchart showing the operation 
of the server in the second embodiment (sheet 2) ; 

FIG. 21 is an example of an input screen in a third 
embodiment ; 
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FIG. 22 is an example of a vehicle database; and 
FIG. 23 is an example of a maintenance/repair history 
database . 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

[0014] Embodiments of the present invention will hereinafter be 
discussed with reference to the accompanying drawings. The 
present invention is not, however, limited to the following 
embodiments . 

[First Embodiment] 

[0015] To begin with, a first embodiment of the present invention 
will be explained. 

<Network Architecture> 
[0016] FIG. lA is a high-level diagram showing an example of a 
network system architecture for a transaction support system 
for setting a price of a transaction target article. FIG. IB 
is a high-level interface diagram of a bulletin board in one 
embodiment of the present invent ion Referring to FIGS . lA and 
IB, the transaction system is configured to operate on a server 
S as the transaction target article price setting support system, 
and the server S connects to a plurality of clients C, as request 
source parties, via an Internet N. The methods by which the 
clients C and the server S are connected to the Internet N, may 
include anyone of the existing connect ion modes (such as a dial-up 
access, an ISDN connection and a leased circuit connection) . 
[0017] The server S functions as a World Wide Web (WWW) server 
and retains information on a Web site (homepage) that includes 
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a bulletin board 1 for browsing sales information of articles 
for sale. The server S provides the client C with access to 
the Web site, including the bulletin board 1, in response to 
a client C request. Each client C functions as a WWW browser, 
and a user at the client C is able to browse the bulletin board 
1 provided by the server S. The bulletin board 1 lists the 
transaction information on the sale articles which are referred 
to as transaction target articles, and the information for each 
transaction target article is registered in an unillustrated 
database of the server S. 

[0018] The user, as a sales applicant (seller) of each client C, 
is allowed to enter information on the bulletin board 1 for the 
article that the user, himself or herself, wishes to sell. In 
addition, when a transaction target article the user, himself 
or herself, wants to purchase is put on the bulletin board 1, 
the user is able to show an intention of purchasing the article 
via the bulletin board 1 to the sales applicant (seller) or 
otherwise (such as delivering an E-mail indicating the intention 
of buying it to the sales applicant) . 

[0019] A sales contract is then agreed upon between the seller 
(the sales applicant ) and the purchase applicant , and the article 
is exchanged for a value equivalent . Aprovider (administrator) 
of the Web site including the bulletin board 1 may be categorized 
as a broker via the bulletin board 1, who collects a brokerage 
fee from the user inputting the sales information on the bulletin 
board 1 . 
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[0020] Further, though not shown, the server S provides each of 
the clients C with a virtual auction site as part of the Web 
site. The user of each client C enters a transaction target 
article the user desires to sell, and enters a minimum price 
thereof. Then, a user of another client C enters a price the 
user is willing to pay for the transaction target article that 
is equal to or higher than the minimum price. Then, the user 
entering the highest price is able to purchase this transaction 
target article. 

[0021] Thus, according to the Internet N based transact ion system, 
the users of the clients C are capable of selling and buying 
transaction target articles via the bulletin board 1 and the 
virtual auction site as well. 

[0022] In the first embodiment, the server S provides each of the 
clients C with access to the bulletin board 1 for inputting 
transaction information (sales information) on vehicle 
components (parts) as transaction targets. The user of the 
client C is either freely able or given a permission to input 
transaction information on the bulletin board 1 for a user's 
own vehicle component (irrespective of whether it is new or used) 
that the user desires to sell . The vehicle components may include 
a privately owned car, a truck, a motor bicycle, etc. 
[0023] At this time, the user must indicate a desired sales price 
for the vehicle component on the bulletin board 1. Here, the 
server S provides the user of the client C with information for 
assisting the user in setting the desired sales price. 
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<Hardware Architectures of Client and Server> 
[0024] Next , hardware architectures of each client C and the server 
S shown in FIG. 1 will be described. FIG. 2, for example, shows 
one embodiment of a hardware architecture for the client C and 
the server S, In this example, all of the clients C are assumed 
to have the same architecture, therefore, only one client C is 
illustrated in FIG. 2. 

[0025] Referring to FIG. 2, the server S, for example, comprises 
a personal computer (PC) , a workstation (WS) , a host computer 
including the above components, or a dedicated server machine 
etc . 

[0026] The server S includes a CPU 2 (corresponding to a reading 
unit, a statistic value calculating unit and an extracting unit) , 
a main memory (MM) 3, an external storage device (secondary 
storage) 4 (corresponding to a storage unit) , a communication 
interface (corresponding to a communication interface I/F: a 
transmitting unit and a receiving unit) 5 connected via a 
communication line to the Internet N, and interface circuits 
(I/F) 6, 7 and 8. 

[0027] A display device 9 such as a cathode-ray tube, a liquid 
crystal display, a plasma display etc is connected to the I/F 
6. A keyboard (KBD) 10 is connected to the I/F 7. A pointing 
device (PD) 11 such as a mouse, a trackball, a joystick, a flat 
point etc is connected to the I/F 8. 

[0028] The external storage device 4 comprises, for example, a 
readable/writable recording medium such as a hard disk, a floppy 
disk, an optical disk, a magneto-optic disk (MO) etc. The 
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external storage device 4 is stored with a plurality of programs 
such as an operating system (OS) , a program relative to a 
communication protocol and a program for the server S to function 
as a WWW server which are all executed by the CPU 2 . The external 
storage device 4 also stores data (such as a text file, an image 
file and an HTML (HyperText Markup Language) file that create 
a homepage containing the bulletin board 1. 
[0029] Moreover, the external storage device 4 stores the 
transaction information the user (sales applicant ) of the client 
C input to the bulletin board 1 for the vehicle component the 
user desires to sell, as well as retaining information in the 
following databases (DBs) for supporting the user on setting 
the price of the vehicle component: a component DB 23, a 
transaction history DB 24 , a price range table 25, an assessment 
item DB 26, an assessment rank table 27, a maintenance/repair 
history DB 28 and a vehicle DB 29. The external storage device 
4 corresponds to a storage unit according to the present 
invention . 

[0030] The CPU 2, when initialized by an operator of server S, 
copies necessary programs and data files to main memory 3 from 
the external storage device 4 , then loads the necessary programs 
and data files into the MM 3 from the external storage device 
4 and executes the loaded program. The CPU 2 thereby executes 
processes related to communications protocols for establishing 
communications with the client C, e.g., a variety of information 
processes, such as processes for providing the homepage 
containing the bulletin board 1 in response to a client C request , 
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and processes for providing support information for setting the 
price of a vehicle component. 

[0031] Namely, the CPU 2 executes programs, whereby the server 
S functions as a transaction target article price setting support 
system including the storage unit, the receiving unit, the 
reading unit, the transmitting unit, the statistic value 
calculating unit and the extracting unit. 

[0032] The main memory (MM) 3 is used as a working area for the 
CPU 2 and also used as a video random access memory (VRAM) for 
storing texts, images and videos displayed on a screen of the 
display device 9. 

[0033] The client C comprises, for example, a personal computer 
(PC) . All the computers used as client C are each capable of 
becoming at least an information processing terminal (DTE: Data 
Terminal Equipment) to the existing Internet N and include 
devices, such as the workstation (WS) , mobile computers , personal 
digital assistants (PDA) like an electronic note etc, a car 
navigation terminal, a mobile telephone (cellular phone) and 
so on . 

[0034] The client C includes a CPU 12, a main memory MM 13, an 
external storage device 14, and a communication interface (I/F) 
15, interfaces (I/Fs) 16, 17 and 18 that are the same as I/Fs 
9, 10 and 11 of the server S. A display device 19 is connected 
to the I/F 16. A KBD 20 is connected to the I/F 17. A PD 21 
is connected to the I/F 18. 

[0035] The external storage device 14 is stored with a variety 
of programs such as an OS, a program for the client C to function 

SUBSTITUTE SPECIFICATION 
Appendix A 



as the WWW browser, and a program related to the communication 
protocols for establishing communications with server S. 
[0036] The CPU 12, when utilized by the user (operator) of the 
client C, copies necessary items of data to MM 13 from the external 
storage device 14, then loads the necessary programs into the 
MM 13 from the external storage device 14 and executes the programs 
The CPU 12 then executes a process for requesting the server 
S to provide the bulletin board 1, a process for transmitting 
to the server S the information that should be put up on the 
bulletin board 1, and a process for requesting the server S to 
provide information for supporting the user to set a price of 
the vehicle component. 

<Processes of Server and Client> 
[0037] Next, a discussion on the processes of the server S and 
of the client C will be made focusing on the process of the server 
S. The user of the client C, when browsing the bulletin board 
1 retained in the server S, accesses the server S by an operation 
on the client C. 

[0038] That is, the user initializes the WWW browser operating 
on the client C and, thereafter, specif ies a URL (Uniform Resource 
Locator) linked to the homepage containing the bulletin board 
1 of the server S. CPU 12 of the client C transmits a request 
to access a Web page corresponding to the URL to the Internet 
N from the communication interface l/F 15. This request is 
received by the server S via the Internet N. 

[0039] Then, the CPU 2 of the server S starts the server processes 
shown in FIG. 3. FIGS, 3 and 4 are flowcharts depicting the 
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processes (the processes in the server S) executed by the CPU 
2 of the server S, Referring to FIG. 3, at step SI the CPU 2 
of the server S is communicating with and accepting a variety 
of requests from the respective clients C (step SI) . 
[0040] Thereafter, the CPU 2, when accepting a client C request 
(step SI; Y) , determines whether or not the accepted request 
is a client C request to access the bulletin board 1 (which is 
a request for providing the Web page of the bulletin board 1) 
(step S2) . 

[0041] If the CPU 2 determines that the client C request is a request 
to access the bulletin board 1 (step S2 ; Y) , the CPU 2 provides 
the client C with the relevant Web page of the bulletin board 
1 (step S3) . To be more specif ic, the CPU 2 reads from the external 
storage device 4 the HTML file, the text file and the image file 
that configure the relevant Web page, and transmits these files 
to the requesting client C via the communication I/F 5. 
Thereafter, the CPU 2 returns the processing to step SI and reverts 
to accepting other requests. 

[0042] The HTML file and other files transmitted from the server 
S are received by the communication interface 15 of the relevant 
client C via the Internet N. Then, the CPU 12 of the client 
C creates, on the MM 13, image data for the Web page based on 
the texts, images and descriptions in the received HTML file. 
The CPU 12 then displays an image corresponding to the Web page 
image data on the screen of the display device 19. 
[0043] The Web page of the bulletin board 1 is thereby displayed 
on the display device 19 of the client C, allowing the user of 
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the client C to browse the sales information of the vehicle 
components for sale on the bulletin board 1. 

[0044] Here, it is assumed that the user of the client C is trying 
to sell a vehicle component (used parts: secondhand parts) 
utilizing the bulletin board 1. In this case, the user of the 
client C must input a sales price for the vehicle component 
(transaction target article) and input the sales information 
(transaction information) thereof on the bulletin board 1. 
[0045] At this time, the user, if unconfident of the sales price 
of the vehicle component and unsure to judge how long it will 
take to complete the transaction, inputs a request for support 
information for setting the sales price by operation of the KBD 
20 and/or the PD 21. Then, the CPU 12 of the client C generates 
a message requesting transaction price setting support 
information, and delivers the message to the server S from the 
communication interface I/F 15 via the Internet N. 
[0046] The CPU 2 of the server S, when receiving the transaction 
price setting support information request from the communication 
interface 5, replies with a "YES" response in step S4 if steps 
SI and S2 have been completed, and advances the processing to 
step S6. Otherwise the CPU 2 replies with a "NO" response in 
step S4 , and the CPU 2 executes other process corresponding to 
the request received in step S5, and loops the processing back 
to step SI. 

[0047] When the processing proceeds to step S6, the CPU 2 transmits , 
to the client C, an input screen 31 for inputting the information 
needed for creating the support information, as shown in Fig. 
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5. When the client C receives the input screen 31, the CPU 12 
displays the input screen 31 on the display device 19. 
[0048] FIG. 5 is an example of the input screen 31 displayed on 
the display device 19. Referring to FIG. 5, the input screen 
31 includes a component (parts) number entry box 32 for the vehicle 
component corresponding to the transaction target article, an 
image displaying area 33 for displaying the image or video of 
the vehicle component , a using period entry box 34 for the vehicle 
component, a desired sales price entry box 35, and a send button 
36. 

[0049] The component number entered in the entry box 3 2 involves 
the use of, for instance, a number allocated beforehand to the 
component by the provider (administrator) of the Web page of 
the bulletin board 1. The image displaying area 33 displays 
an image of the component scanned by, e.g. , a camera type image 
scanner (not shown) connected via an unillustrated interface 
to the client C . In one configuration, input button 33a provided 
on the input screen 3 1 is used as a start button for a scan operation 
of the image scanner. 

[0050] In this respect, when the user of the client C specifies 
a component image file (GIF (Graphics Interchange Format) , 
Windows BMP, JPEG (Joint Photographic Experts Group), etc.) 
recorded on the external storage device 4, the component image 
may also be displayed in the display area 33. In this case, 
the component image file is created from a digital image 
photographed by, e.g., a digital camera or a digital video camera, 
and is recorded on the external storage device 4 . 
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[0051] The time period (using period) which the user has been using 
the vehicle component concerned, is entered, for example in 
monthly units in the entry box 34. The using period unit may 
be arbitrarily set to a year, date, hour and minute as the unit 
for the using period. The sales price (desired sales price) 
of the vehicle component , which is desired by the user , is entered 
in the entry box 35. 

[0052] The user, when the input screen 31 is displayed on the display 
device 19, inputs the component image to the client C by 
manipulating the KBD 2 0 and/or the PD 21, and enters the component 
number, the using period and the desired sales price in the entry 
boxes 32, 34 and 35. Thereafter, when depressing the send button 
36, by manipulating the KBD 20 or the PD 21, the CPU 12 transmits, 
to the server S, the identifying information of the vehicle 
component (the image and the component number) , the quality 
evaluating information (using period) and the desired sales price 
that have been inputted via the input screen 31. 
[0053] The CPU 2 of the server S, after transmitting input screen 
31 to the client C in step S6, waits for the completed input 
screen 31 to be transmitted from the client C (step S7) . Then, 
the CPU 2, after receiving the relevant information from the 
client C (step S7; Y) , advances the processing to step S8 . 
[0054] In step S8, the CPU 2 accesses the component database (DB) 
2 3 stored in the external storage device 4 and reads, from the 
component DB 23, any records corresponding to the component 
number received from the client C into the main memory MM 3, 
and advances the processing to step S9. 
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[0055] FIG. edepictsanexampleof a data structure of the component 
DB 23 shown in FIG. 2. Referring to FIG. 6, the component DB 
23 retains at least one record consisting of a component number 
field, a component code field, a standard price field, a field 
of using condition A, a filed of using condition B and a field 
of using limit (using condition C) . 

[0056] The component number is a unique number allocated to the 
component by the administrator of the Web site, and is used as 
the identifying information (ID) of the component. The 
component code is a code assigned by the administrator based 
on the vehicle component function irrespective of a category 
of the vehicle, and is used as information for categorizing the 
component. The standard price is a standard retail price (a 
so-called fixed price) of the component. Note that the standard 
price may also be a price accounting for a market price such 
as an actual retail price on the market. 

[0057] Further, Each of the using conditions A, B and C is defined 
as quality information indicating a quality corresponding to 
the using period of the vehicle component , and i s set per component . 
The using limit indicates a using period that has expired with 
the value of the component becoming nothing (zero) . When the 
using period exceeds the using limit component is dealt with 
as valueless. A record in the component DB 23 is created each 
time a transaction target article is input and registered on 
the bulletin board 1 as a for sale item. 

[0058] In step S9, the CPU 2 of the server S compares the using 
period received from the client C with the using limit read from 
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the MM 3, and determines whether the using period exceeds the 
using limit. If the using period exceeds the using limit (step 
S9; Y) , the CPU 2 advances the processing to step SIO and executes 
an error process. Namely, the CPU 2 creates an error message 
saying that the component the user desires to sell has exceeded 
its using period limit and is valueless (impossible of being 
sold) , and delivers this message to the client C. The error 
message is displayed on the display device 19 of the client C. 
Thereafter, the CPU 2 finishes the process in step SIO and returns 
the processing to step SI. 

[0059] By contrast, if the using period does not exceed the using 
limit (step S9; N) , the CPU 2 obtains a using condition of the 
component (step Sll) . That is, the CPU 2 compares the using 
period with each of the using period conditions A, B and C in 
the record, and specifies the using condition coincident with 
the input using period. 

[00601 Next, the CPU 2 reads into the MM 3, all of the records 
with the corresponding component number received from the client 
and with the corresponding using condition obtained in step Sll 
out of the transaction history database (DB) 24 stored in the 
external storage device 4 (step S12; see FIG. 4) , and advances 
the processing to step S13 . 

[0061] FIG. 7 is an example of a data structure of the transaction 
history DB 24 shown in FIG. 2. Referring to FIG. 7, the 
transaction history DB 24 is a database stored with a history 
of the transactions initiated via the bulletin board 1. The 
transaction history DB 24 consists of a single record or a 
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plurality of records each composed of fields such as an 
advertisement number, a transaction number , a transact ion date , 
a component number, a component code, a using condition, a using 
period, an advertisement starting date, a transaction price and 
anassessment rank. Eachof the records stored in the transaction 
history DB 24 corresponds to transaction achievement information 
according to the present invention. 

[0062] The advertisement number is a unique number used as 
information for specifying the sales information (transaction 
information) input and displayed (advertised) on the bulletin 
board 1 . The transact ionnumber is a unique number for specifying 
the transactions initiated via the bulletin board 1. The 
transaction date is a year, month and date when the transactions 
were initiated, and the administrator of the bulletin board 1 
sets a date when the sales contract was adequately completed 
or a date when the vehicle component was exchanged for a value 
equivalent . 

[0063] The advertisement starting date is a date when the sales 
information starts being available (advertised) on the bulletin 
board 1. The transaction price is the amount of money set as 
the value equivalent to the component in the sales contract for 
the vehicle component . The assessment rank indicates a quality 
based on a predetermined assessment standard set by the 
administrator of the bulletin board 1. Note that each time a 
transaction is initiated via the bulletin board 1, a new record 
of the sales transaction initiated is registered in the 
transaction history DB 24 as one of the other processes in step 
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[0064] In step S13, the CPU 2 obtains an average number of bid 
tender days during which bids for the component in a price range 
(price zone) inclusive of the desired sales price have been 
received from the clients C, using single record or a plurality 
of records (refer as "first extraction record (s)") extracted 
from the transaction history DB 24 in step S12 . The average 
number of bid tender days is a number of days required for 
initiating the transaction of the transaction target article 
since the transaction information of the transaction target 
article was advertised on the bulletin board 1, and indicates 
the period of time required for initiating the transaction. The 
transaction agreement time may be selected from, for example, 
the time when the purchaser conveyed an intention to purchase 
to the seller, the time when the intention of the purchaser was 
conveyed to the administrator of the bulletin board 1, on the 
time when the component was exchanged with the value equivalent . 
[0065] To describe step S13 in depth, the CPU 2 accesses the price 
range table 25 stored in the external storage device 4, and 
determines which price range the desired sales price falls within 
in the price range table 25. 

[0066] FIG. 8 is an example of the price range table 25 shown in 
FIG. 2. As shown in FIG. 8, a price range table 25 is provided 
for every component number . The price range table 2 5 may, however , 
only be provided for every component code, 

[0067] Further, the price range table 25 in this example provides 
five price ranges such as 0 5000 yen, 5001 - 8000 yen, 8001 
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- 10000 yen, 10001 - 15000 yen and 15001 - 99999 yen. The CPU 
2 compares the desired sales price with each of the price ranges, 
thereby determining the price range inclusive of the desired 
sales price. 

[0068] Note that the number of the price ranges and a size of each 
price range may be properly set. Further, as a substitute for 
using the price range table 25, a minimum price and a maximum 
price that define a price range may also be calculated to set 
different price ranges, such as setting a range for every 2 0 00 
yen or 3 0 00 yen and so on. 

[0069] After determining the price range embracing the desired 
sales price, the CPU 2 extracts records in which the transaction 
prices falls within the price range as a second extraction record 
from a first extraction record. Subsequently, the CPU 2 
subtracts the advertisement starting date from the transaction 
date with respect to each of the second extraction records, and 
divide a sum of the subtracted results by the number of the second 
extraction records, thereby obtaining an average number of bid 
tender days . 

[0070] Thereafter, the CPU 2 creates a message containing the using 
condition obtained in step Sll and the average number of bid 
tender days obtained in step S13 , and del ivers the created message 
to the relevant client C (step S14) . Thereafter, the CPU 2 
advances the processing to step S15, 

[0071] When receiving the message delivered from the server S, 
the client C displays the received message on the display device 
19. FIG. 9 is an example of a message 37 displayed to the sales 
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applicant that corresponds to the process in step S13 . Thus, 
the sales applicant (the user of the client C) is provided with 
the using condition as the quality information of the transaction 
target article and the average number of bid tender days in the 
price range inclusive of the desired sales price as pieces of 
support information for setting the sales price. 
[0072] In step S15, the CPU 2 obtains the average number of bid 
tender days for every price range and subsequently obtains an 
average transaction price for every price range (stepSlS) . The 
processes in steps S15 and S16 will hereinafter be explained 
in greater detail. 

[0073] The CPU 2 creates a first collection table based on the 
price range table 25 referred to in step S13 in the main memory 
MM 3. FIG. 10 is an example of a first collection table 38. 
The first collection table 38 is a table for collecting the number 
of records, the number of days and the transaction price, 
corresponding to each of the price ranges retained in the price 
range table 25. When the first collection table 38 is created, 
the number of records, the number of days and the transaction 
price, which correspond to each of the price ranges, are each 
set to zero as an initial value (see FIG. 10) . 
[0074] The CPU 2, when creating the first collection table 38, 
with respect to a certain first extraction record, refers to 
the price range inclusive of the transaction price thereof, and 
increments [the number of records] in the first collection table 
38 by "1" ("1" is added to the number of records) , corresponding 
to the relevant price range. Subsequently, the CPU 2 subtracts 
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the advertisement starting date from the transaction date in 
the first extraction record, and adds a value of this subtracted 
result to [the number of days] corresponding to the relevant 
price range. Further, the CPU 2 adds the transaction price in 
the first extraction record to [the price] corresponding to the 
relevant price range. The CPU 2 executes the processes given 
above with respect to all the first extraction records. 
[0075] Thereafter, the CPU 2, when finishing the above processes 
for all the first extraction records, divides a value of each 
[number of days] and a value of each [price] retained in the 
first collection table 38 by [the number of records] 
corresponding thereto . Thus , the CPU 2 obtains an average value 
(an average number of bid tender days) of [the number of days] , 
and also an average value (an average transaction price) of the 
[price] . 

[0076] Thereafter, the CPU 2 creates a message containing the 
average number of bid tender days and the average transaction 
price that have thus been obtained, and transmits the message 
to the relevant client C (step S17) . After this process, the 
CPU 2 advances the processing to step S18. 

[0077] After receiving the message delivered from the server S, 
the client C displays this message on the display device 19. 
FIG. 11 is an example of a message 39 to the sales applicant, 
corresponding to the processes in steps S15 and S16. The user 
of the client C is thus provided with the using condition 
corresponding to the quality information on the transaction 
target article (vehicle component) as support information for 
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setting the sales price . The user of the client C is also provided 
with the average number of bid tender days and the average 
transaction price for every price range. 

[0078] In step S18, the CPU 2 obtains the average number of bid 
tender days at an interval of a predetermined advertising period . 
Subsequently, the CPU 2 obtains the average transaction price 
days at predetermined advertising period (S19) interval. The 
following is the details of steps S18 and S19. 
[0079] The CPU 2 creates a second collection table 4 0 based on 
a predetermined advertising period (e.g. , 10 days, 20 days and 
3 0 days) in the MM 3 . FIG. 12 is an example of a second collect ion 
table 40. The second collection table 40 collects and retains 
the number of records, the number of days and the transaction 
prices corresponding to each for the predetermined advertising 
periods. When the second collection table 40 is created, the 
number of records, the number of days and the transaction prices 
corresponding to each of the predetermined advertising periods, 
are each set to zero as an initial value (see FIG. 12) . 
[0080] When creating the second collection table 40, with respect 
to a certain first extraction record, the CPU 2 increments [the 
number of records] in the second collection table 40 by ''1" ("1" 
is added to the number of records) , corresponding to the 
advertising period containing the number of days obtained by 
subtracting the advertisement starting date from the transaction 
date. Subsequently, the CPU 2 subtracts the advertisement 
starting date from the transaction date in the first extraction 
record, and adds a value of this subtracted result to [the number 
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of days] corresponding to the relevant advertising period. 
Further, the CPU 2 adds the transaction price in the first 
extraction record to [the price] corresponding to the relevant 
advertising period . The CPU 2 executes the processes given above 
with respect to all the first extraction records. 
[0081] Thereafter, the CPU 2, when finishing the above processes 
for all the first extraction records, divides a value of each 
[number of days] and a value of each [price] retained in the 
second collection table 40 by [the number of records] 
corresponding thereto . Thus , the CPU 2 obtains an average value 
(an average number of bid tender days) of [the number of days] , 
and also an average value (an average transaction price) of the 
[price] . 

[0082] Thereafter, the CPU 2 creates a message containing the 
average number of bid tender days and the average transaction 
price that have thus been obtained, and transmits this message 
to the relevant client C (step S20) . After this process, the 
CPU 2 loops the processing bacJc to step SI. 

[0083] When receiving the message delivered from the server S, 
the client C displays the received message on the display device 
19. FIG. 13 is an example of a message 41 displayed to the sales 
applicant, corresponding to the processes in steps S18 and S19. 
The component sales applicant (the user of the client C) is thus 
provided with the using condition corresponding to the quality 
information on the transaction target article (vehicle 
component) as support information for setting the sales price. 
The user of the client C is also provided with the average number 
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of bid tender days and the average transaction price at the 
predetermined advertising period interval. 

[0084] Note that the first embodiment has given the example in 
which the predetermined advertising period is set to less than 
10 days, 11-20 days, 21-30 days, and 31 days or longer, however, 
a length of the advertising period may adequately set to any 
desired value. 

<Operation in First Embodiment> 
[0085] According to the first embodiment , if the user of the client 
C wishes to sell a vehicle component via the bulletin board 1, 
the client C requests support information for setting the price 
of the vehicle component from the server S. The client C is 
given the input screen 31 to input the information (the 
information for identifying the transaction target, and the 
quality evaluation information) needed for providing the support 
information. 

[0086] Then, the client C supplies the server S with the identifying 
information (the image and the component number) of the 
transaction target article (vehicle component) , the quality 
evaluation information (the using period) for this component 
and the desired sales price via the input screen 31. Then, the 
server S evaluates the quality (the using condition) of the 
component on the basis of the identifying information of the 
component and the quality evaluation information (the using 
period) (step Sll) . 

[0087] Subsequently, the server S obtains the average number of 
bid tender days in the price range embracing the desired sales 
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price, using the respective items of information received from 
the client C and the transaction achievement information (the 
records in the transaction history DB 24) of the sales conducted 
via the bulletin board 1 (step S13) . Then, the server S supplies 
the client C with the using condition and the average number 
of bid tender days as support information (step S14) . 
[0088] The support information is displayed on the display device 
19 of the client C. The user (the sales applicant) of the client 
C is provided the quality of the sales target component and the 
average number of bid tender days (how long it took to find a 
purchaser for the relevant component at the desired sales price) . 
[0089] Moreover, the server S obtains the average number of bid 
tender days and the average transaction price for every price 
range with respect to the transaction target article (steps S15 
and S16) , and supplies this data to the client C (step S17) . 
The sales applicant is thereby able to determine which price 
range is proper for the transaction target article and how soon 
a purchaser will be located in that price range. 
[0090] Further, the server S obtains the average number of bid 
tender days and the average transaction price at predetermined 
advertising period intervals with respect to the transaction 
target article (steps S18 and S19) , and supplies this data to 
the client C (stepS20) . With this operation, the sales applicant 
can determine the relationship between the length of the 
advertising period and the transaction price for the transaction 
target article. 
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[0091] As discussed above, the sales applicant can receive the 
quality information for the transaction target article by 
receiving the using condition information as support information, 
and can utilize these pieces of information as key factors in 
setting the price of the vehicle component concerned. Further, 
the sales applicant receives information on the transaction 
achievements (the average number of bid tender days and the 
average transaction price as statistic values) for the component 
the user wants to sell , by the component number andusing condition 
(the identifying information and the quality information are 
the same) as support information. The sales applicant is thereby 
capable of predicting how soon the purchaser can be located by 
knowing the affect of the price set for the transaction target 
article . 

[0092] Accordingly, the sales applicant is capable of setting the 
desired sale price of the sales target component to a price that 
leads to a desirable result (such as being sold higher and sooner) 
to the sales applicant. Namely, the sales applicant is able 
to properly set the price. The administrator of the bulletin 
board 1 is capable of increasing the number of users of the bulletin 
board 1 and of improving the profits, in the case of collecting 
the fee for using the bulletin board 1 from the user thereof. 
[0093] Incidentally, in the first embodiment, the processing 
results in step S13, steps S15 and S16 and steps S18 and S19, 
are individually transmitted to the client C. Alternately, the 
server S may transmit one message to the client C which includes 
messages 37, 39 and 41 when finishing the process in step S19. 
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[0094] Further, in the first embodiment, the process in step S13, 
the processes in steps S15, S16 and the processes in steps S18, 
S19 are described being executed in series after receiving a 
request for one item of support information. The client C may, 
however, request only one of the processes described above. 
[0095] Moreover, the process in step S13, the processes in steps 
S15, S16 and the processes in steps S18 , SI 9 may take any sequence . 
Further, the process in step S15 and the process in step S16 
may be reversed in order, and the process in step S18 and the 
process in step S19 may also be reversed in order. 
[0096] Furthermore, the first embodiment describes the server S 
as providing the support information to the client C. However, 
the external storage device 14 of the client C can store the 
same information as is stored in the external storage device 
4, and the support request input via the KBD 2 0 or the PD 21 
may be answered by the CPU 12 of the client C, which may execute 
the processes shown in FIGS. 3 and 4, and the messages 37, 39, 
41 may be displayed on the display device 19 . Namely, the present 
invention may be contained with a stand-alone computer. This 
is the same with second and third embodiments. 

[Second Embodiment] 
[0097] Next, a second embodiment of the present invention will 
be discussed. The second embodiment contains aspects and 
features similar to the first embodiment . Hence, the discussion 
will concentrate on differences therebetween. 

[0098] The processes of the server S and the client C in the second 
embodiment are the same as those in the first embodiment, as 
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far as the steps SI - S5 shown in FIG. 3 are concerned. In the 
second embodiment, however, an input screen transmitted to the 
client C from the CPU in step S6 is different from the input 
screen in the first embodiment. 

[0099] FIG. 19 is a process flowchart for the server S (the processes 
of the CPU 2 ) in the second embodiment . In the second embodiment , 
the CPU 2 transmits input screen 31A in place of the input screen 
31 to the client C in step S106 corresponding to step S6, as 
shown in FIG. 21. 

[0100] FIG. 14 is an example of the input screen 31A in the second 
embodiment. As shown in FIG. 14, the input screen 31A is 
different from the input screen (see FIG. 5) in that input screen 
31A does not include the using period entry box 34 and input 
screen 31A substitutes a [Next] button 43 for the transmission 
button 36. 

[0101] When the client C receives and displays input screen 31A 
on the display device 19, the user of the client C inputs an 
image, a component number and a desired price by the same method 
as used in the first embodiment. Then, the [Next] button 43 
is depressed by manipulating the KBD 20 or the PD 21. 
[0102] Then, the CPU 12 of the client C transmits, to the server 
S, a request for a second input screen 44 (see FIG. 16) which 
contain at least a component number of the transaction target 
article. Upon receiving this request (step S107; Y) , the CPU 
2 of the server S accesses the component database DB 23 and reads 
from the component DB 23 a component code corresponding to the 
component number received from the client C into the MM 3 (step 
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S108) . 

[0103] Next, the CPU 2 refers to the assessment item database DB 
2 6 stored in the external storage device 4 and reads assessment 
check items into the MM 3 corresponding to the component code 
read into the MM 3, thereby creating display data (based on an 
HTML format etc) on the second input screen 33 (step S109) , 
[0104] FIG. 15 is an example of a data structure of the assessment 
item DB 2 6 shown in FIG. 2 . The assessment item DB 2 6 is provided 
for, e.g., every component code. The assessment item DB 26 
retains information on the assessment items of a component and 
scores (points) corresponding to answers to questions about the 
assessment items in a structure suited to a layout on the second 
input screen 44 . In the example shown in FIG . 15, the assessment 
items in the assessment item DB 2 6 are a using period, cleaning 
of OO portion, polishing of OO portion, rust, scraped flaw, 
scratches and a recess. 

[0105] When creating the display data on the second input screen 
44, the CPU 2 transmits the display data to the client C (step 
SllO) . Upon receiving the display data, the client C displays 
the second input screen 44 based on the display data on the display 
device 19. 

[0106] FIG. 16 is an example of the second input screen 44. 
Referring to FIG. 16, the second input screen 44 includes the 
using period entry box 34, an answer box 44a to the questions 
about the assessment items retained in the assessment item DB 
26, and the send button 36. Plural concepts of answers to the 
questions about the assessment items are displayed in the answer 
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box 44a, and a check box containing check circles for indicating 
the respective answers is provided. 

[0107] The user of the client C enters the using period in the 
entry box 34 and checks the check circle corresponding to the 
answer corresponding to the question about each assessment item, 
thereby answering the question. Then, when finishing answering 
all the questions, the user depresses the send button 36. 
[0108] Then, the CPU 12 of the client C transmits, to the server 
S, the image, the component number and the desired sales price 
that have been input on input screen 31A, and the answers to 
the questions about the using period and other assessment items 
that have been input on second input screen 44. 
[0109] After receiving the respective pieces of information via 
the communication interface I/F 5 (step Sill) , as in the first 
embodiment, the CPU 12 of the server S determines whether or 
not the using period exceeds the using limit (step S112) . If 
over the using limit (step S112; Y) , the error process (step 
S113; the same as step SIO) previously described is executed. 
[0110] If the using period does not exceed the using limit (which 
does not correspond to the using condition C) (step S112; N) , 
the CPU 2 refers again to the assessment item DB 2 6 used for 
creating the display data on the second input screen 44, and 
calculates assessment scores (points) based on the answers to 
the questions, which have been received from the client C (step 
S114) . For example, the CPU 2 sets a base of the assessment 
score to 100, and adds or subtracts a score corresponding to 
the answer to the question to or from the base score 100. 
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[0111] Next, the CPU 2 obtains an assessment rank using the 
calculated result of the assessment score (step S115) . That 
is, the CPU 2 refers to the assessment rank table 27 stored in 
the external storage device 4 and reads therefrom the assessment 
rank corresponding to the calculated result into the MM 3 . 
[0112] FIG. 17 is an example of an assessment rank table 27 shown 
in FIG. 2, As shown in FIG. 17, the assessment rank table 27 
is stored with ranges of the assessment scores (points) and the 
assessment ranks that correspond to each range. Note that the 
assessment rank is set in five categories A2 , Al , B2 , Bl and 
C in this example, however, the (number of) categories of the 
assessment ranks may be set as needed. 

[0113] Next, the CPU 2 obtains the average number of bid tender 
days and the average transaction price using the assessment rank 
acquired (step S116) . To be specif ic , the CPU 2 extracts (reads 
into the MM 3 ) al 1 the records having the component number received 
from the client C and the assessment rank acquired as third 
extraction records . 

[0114] Subsequently, from the extracted third extract ion records , 
the CPU 2 obtains the average number of bid tender days and the 
average transaction price per price range by using the price 
range table 25 and the first collection table 38 and the same 
method as steps S15 and S16 in the first embodiment. 
[0115] Thereafter, the CPU 2 creates a message containing the 
acquired assessment rank, the assessment score, the average 
number of bid tender days and the average transaction price per 
price range, and delivers this message to the relevant client 
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C (step S117) . 

[0116] The client C thereby receives and displays this message 
on the display device 19. FIG. 18 is an example of a message 
46 displayed on the display device 19. As shown in FIG. 18, 
the assessment score and the assessment rank of the transaction 
target article are displayed to the user (sales applicant) of 
the client C. Further, the average number of bid tender days 
(the average advertising period) and the average transaction 
prices for every price range with respect to the transaction 
target article having the above assessment rank and the same 
component number, are also displayed to the user. 
[0117] Note that the average number of bid tender days in the price 
range inclusive of the desired sales price may be obtained based 
on the assessment rank by substantially the same method as step 
S13 in the first embodiment, then transmitted to the client C 
and displayed on the display device 19 (the average number of 
bid tender days may be provided as support information to the 
sales applicant) in the second embodiment. 

[0118] Further, the average number of bid tender days and the 
average transaction price at the predetermined advertising 
period interval may be obtained based on the assessment rank 
using the second collection table 40 by substantially the same 
method as steps SIB and S19 in the first embodiment, and then 
transmitted to the client C and displayed on the display device 
19 in the second embodiment. 

[0119] In accordance with the second embodiment also, the sales 
applicant is able to set a proper price for the transaction target 
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article with reference to the support information (the assessment 
rank, the average number of bid tender days and the average 
transaction price) . Further, in the second embodiment, the 
quality of the component is evaluated based on the plurality 
of assessment items (assessment standards) including the using 
period. Thus, in the second embodiment, the quality of the 
transaction target article is examined in greater details than 
in the first embodiment, and hence a gap between the condition 
of the transaction target article and the transaction price can 
be made smaller than in the first embodiment. 

[0120] Note that while the assessment rank is defined as one field 
of the record in the transaction history database DB 24, in the 
second embodiment of the present invention, the assessment item 
database DB 2 6 and the assessment rank table 2 7 use database 
structures that are not used in the first embodiment . Therefore , 
in the first embodiment, the assessment ranks in the transaction 
history DB 24, the assessment item DB 26 and the assessment rank 
table 2 7 are unnecessary. 

[0121] Furthermore, according to the second embodiment, the 
assessments about the rust, scraped flaw, scratches and recesses 
are made based on the answers of the sales applicant. 
Alternatively, these assessment items are removed from the 
assessment item DB 2 6 and the second input screen 44, and the 
assessment score (points) may be calculated using the vehicle 
component image received via the second input screen 44. In 
this embodiment, the component image is displayed on the display 
device 19, and the operator of the server S may input a score 
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corresponding to a result of the assessment or the CPU 2 may 
execute a predetermined process of the image in the server S, 
whereby the assessment score can be automatically calculated. 

[Third Embodiment] 
[0122] Next, a third embodiment of the present invention will be 
discussed. The third embodiment contains aspects and features 
similar to the first embodiment, and the discussion will 
therefore be focused on the differences from the first 
embodiment . 

[0123] FIG. 20 is a flowchart showing processes (of the CPU 2) 
of the server S in the third embodiment. The processes of the 
server S and the client C in the third embodiment are the same 
as those in the first embodiment as far as steps SI - S5 shown 
in FIG. 3 are concerned. In the third embodiment, however, an 
input screen transmitted to the client C in step S6 is different 
from the input screen in the first embodiment . 
[0124] In accordance with the third embodiment, in the client C, 
a type and a frame number of the vehicle from which the transaction 
target article is taken, are input on the input screen. In the 
third embodiment, the data on input screen 3 IB is transmitted 
to the client C in step S206, corresponding to step S6. 
[0125] FIG. 21 is an example of the input screen 3 IB in the third 
embodiment. As shown in FIG. 21, the input screen 3 IB is 
different from the input screen 31 (see FIG. 5) in that vehicle 
type entry box 4 8 and a frame number input box 4 9 are added to 
the configuration of the input screen 31. 
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[0126] When the client C receives and displays input screen 3 IB 
on the display device 19, the user of the client C inputs an 
image, a component number and a desired price by the same method 
as the first embodiment. At this time, the user is also able 
to selectively input data for either the using period, the vehicle 
type and the frame number . 

[0127] Namely, the input screen 3 IB is configured so that if either 
the using period or the vehicle type and the frame number are 
input, the other can not be input. If neither the using period 
nor the vehicle type and the frame number are input, input screen 
31b is configured such that the data can not be transmitted to 
the server S even when depressing the send button 36. 
[0128] When finishing the data entry process on the input screen 
31B, the user depresses the send button 36 by manipulating the 
KBD 20 or the PD 21. The CPU 12 of the client C transmits the 
image, the component number, the desired price and the using 
period (or the vehicle type and the frame number) to the server 
S, 

[0129] When receiving the above information from the client C (step 
S207) , the CPU 2 of the server S determines whether or not the 
information received contains the vehicle type and the frame 
number of the vehicle (step S208) . At this time, if the received 
data contains the vehicle type and the frame number (step S208; 
YES) the CPU 2 advances the processing to S209. Conversely, 
if the vehicle type and the frame number are not contained (step 
S2 08; NO) in the received data, the CPU 2 determines that the 
information received from the client C does not contain the 
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vehicle type and the frame number but the using period, and diverts 
the processing to step S8 in FIG. 3. After diverting to step 
SB, the subsequent processing is the same as discussed under 
the first embodiment. 

[0130] When the processing proceeds to step S209, the CPU 2 searches 
the vehicle database DB 2 9 stored in the external storage device 
4 using the vehicle type and the frame number, and thus determines 
whether or not a record containing the vehicle type and the frame 
number is stored therein. 

[0131] FIG. 22 is an example of the vehicle DB 2 9 shown in FIG. 
2. As shown in FIG. 22, the vehicle DB 2 9 retains records each 
consisting of fields such as a vehicle type, a frame number and 
an operation starting date. 

[0132] If a record containing the type and the frame number does 
not exist in the vehicle DB 29 (step S209 ; NO) , the CPU 2 determines 
that the information received from the client C contains the 
using period, and diverts the processing to SB in FIG. 3 . After 
diverting to SB, the subsequent processes are the same as 
discussed under the first embodiment. If a record containing 
the vehicle type and the frame number exists in the vehicle DB 
29 (step S209; YES) , the CPU 2 reads the relevant record from 
the vehicle DB 2 9 into the MM 3. 

[0133] Next, the CPU 2 obtains a component code corresponding to 
the component number received from the client C (step S211) . 
This process is executed in such a way that the CPU 2 searches 
an unillustrated component number/component code conversion 
table stored in the external storage device 4 by use of the 
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component number. Note that the CPU 2 may also obtain the 
component code by searching the component database DB 23. 
[0134] Next , the CPU 2 determines whether or not a record containing 
the component code, the vehicle type and the frame number is 
stored in the maintenance/repair history database DB 28 stored 
in the external storage device 4 (step S212) . 

[0135] FIG. 23 is an example of the maintenance/repair history 
DB 28 shown in FIG. 2. The maintenance/repair history DB 28 
retains a single or plurality of records each consisting of fields 
such as a vehicle type, a frame number, a work date, a component 
code and a work classification. The work classification field 
takes a value of any one of [exchange] , [cleaning] , [plate 
working] and [coating] in accordance with the type of the 
maintenance or the repair (restoration) . 

[0136] If the record containing the component code, the vehicle 
type and the frame number is not stored in the maintenance/repair 
history DB 28 (step S212; NO) , The CPU 2 advances the processing 
to step S217. If a record is stored therein (step S212; YES) , 
the CPU 2 advances the processing to step S213, and reads that 
record into the main memory MM 3 . 

[0137] Subsequently, the CPU 2 determines whether or not the work 
classification in the record read into the MM 3 is [exchange] 
(step S214) . If the work classification is [exchange] , the 
processing proceeds to step S216. If the work classification 
is not [exchange], the processing goes forward to stepS215. 
[0138] In step S215, the CPU 2 determines whether or not the work 
classification in the record in the maintenance/repair history 
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DB 28 that has been read into the MM3 is [cleaning] . If the 
work classification is [cleaning] , the processing proceeds to 
step S216. If the vjork. classification is not [cleaning] , the 
processing diverts to step S217. 

[0139] In step S216, the CPU 2 obtains, as the using period, a 
period extending from [work date] in the record in the 
maintenance/repair history DB 28 that has been read into the 
MM 3 up to the present time. Thereafter, the CPU 2 loops the 
processing back to step S8 in FIG. 3, and executes the same 
processes as those in the first embodiment. 

[0140] In step S217, the CPU 2 obtains, as the using period, a 
period extending from [operation starting date] in the record 
in the vehicle DB 2 9 that has been read into the MM 3 in step 
S210 up to the present time, and loops the processing back to 
step S8. Thereafter, the CPU 2 executes the same processes as 
those in the first embodiment. 

[0141] According to the third embodiment, the transaction target 
articles of the sales applicant is removed from the vehicle, 
and the same component is fitted to the vehicle in a maintenance 
and repair shop related to the administrator of the bulletin 
board 1 , in which case the type and the frame number of the vehicle 
are entered on the input screen 31b instead of the using period, 
and the using period is automatically set based on these pieces 
of data. Accordingly, under above conditions, even if the sales 
applicant forgets the using period of the component, the using 
condition of the component can be determined based on the precise 
using period. 
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[0142] Note that the maintenance/repair history DB 28 , the vehicle 
DB 2 9 shown in FIG. 2, the component number/component code 
conversion table (not shown) and the input screen 3 IB, are used 
in only the third embodiment and may not be therefore provided 
if the transaction system in the first embodiment is carried 
out. Further, the first through third embodiments may be 
properly combined within the scope of the present invention 
without departing from the purpose of the present invention. 
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